Security Hub をリージョン集約・Organizations 統合する場合の管理アカウントについて考える

管理アカウントではアクセスを最小限まで絞りつつも、普段使用しないリージョンの扱いについて考えてみました。

#AWS Control Tower

#AWS Organizations

#AWS Security Hub

#AWS

平木佳介

2023.09.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部の平木です！

Security Hub を使って AWS 内のセキュリティサービスの通知を集約していますか？

今回はその集約機能についてタイトルにもある
「Security Hub をリージョン集約・Organizations 統合する場合の管理アカウントについて考える」
を題材に執筆しました。

Security Hub の検知集約とは

Security Hub を活用し Organizations 統合とリージョン集約することで、
マルチアカウント環境で使用している AWS のセキュリティサービス（SecurityHub と統合できるもの）の検知を1つのアカウントの1つのリージョンに集約することが可能です。

詳細はこちらのブログをご覧ください。

Control Tower を使用している場合の管理アカウントの状況

しかし下記シチュエーションの場合、事情が変わってきます。

Control Tower を使用し、リージョン拒否コントロールを有効化させている
Control Tower 配下のアカウントへ Security Hub の委任管理アカウントを設定している

図示すると下記のようになります。

図示した通りホームリージョンと管理対象リージョンについては、 Security Hub を有効化するかと思います。

しかし、管理アカウントのその他のリージョン（ここでは、拒否リージョンと呼びたいと思います）
についてはいかがでしょうか。

Control Tower 配下の委任管理アカウントやメンバーアカウントについては、
リージョン拒否コントロールによりホームリージョンと管理対象リージョン以外の使用は制限されています。

しかし 2023年9月4日現在で管理アカウントは SCP（サービスコントロールポリシー）で
AWS アカウントを制御できないため、 Control Tower でリージョン拒否コントロールを設定していても
制限はかかっていない状態となります。（できれば制限かけられるようになると期待したいですが）

この仕様により、普段は使っていないリージョンは何かあっても気づきにくいことから、
セキュリティの観点で管理アカウントについては拒否リージョンについても対処すべきか悩む方もいるかもしれません。

管理アカウントの Security Hub を全リージョン有効化するか否か

そこで全リージョン有効化するか否かのメリットデメリットを挙げてみたいと思います。
※管理アカウントへのアクセスは極限まで制限していることを前提に執筆しています。

管理アカウントの拒否リージョンでは Security Hub を有効化しない場合

図示してみると下記のようになります。

メリット

管理アカウントを Security Hub のメンバーアカウントとして追加することで、
管理アカウントを含めた全てのアカウントの検知を委任管理アカウントへ集約できます。
これにより非常に構成としてはシンプルかつ分かりやすいものになります。

また、セキュリティイベントを通知させるための EventBridge も委任管理アカウントにだけ作ればよいため、
管理アカウントへ作成するリソースが減り、そのリソースがあることを認識する運用負荷の軽減につながります。

デメリット

もちろんですが、管理アカウント上の拒否リージョンで Security Hub を有効化しないことで、
そのリージョンに対するセキュリティ上のリスクは出てきます。
ここを一旦今後のアップデートに期待し、妥協するか否かは検討の余地があります。

しかしこのリージョンへのリスクを減らすために下記対応でリスクを軽減できると思います。

GuardDuty については全リージョン有効化する
IAM Access Analyzer を活用し意図していない外部エンティティからのアクセスを許可していないか確認する

上記対応をするだけでもリスク軽減につながると思います。
IAM Access Analyzer ではスイッチロールのような外部エンティティを許可する IAM ロールを作成した際にも検知可能です。
IAM ロールはグローバルサービスのためリージョナルサービスである IAM Access Analyzer では、
作成したリージョン全てのアナライザーで検知することが可能です。
そのため、拒否リージョンで作成していなくても問題なく検知可能ということになります。

便利ですね。
ただ全リージョンで検知可能でノイズになる可能性がありますので、アーカイブルールを駆使したり工夫は必要です。
IAM Access AnalyzerのIAM Roleをアーカイブするルールを複数リージョンで作成するスクリプト | DevelopersIO

この構成を選ぶ場合では以下のようなケースが考えられます。

まずは普段使用しているリージョンのセキュリティ運用を徹底したい。
管理アカウントへは極力運用が必要なリソースを作成したくない

しかし、拒否リージョンに対してもセキュリティはどうしても担保したいという場合に次の方法を検討します。

管理アカウントでは全リージョンで Security Hub を有効化させる

図示してみると下記のようになります。

Organizations 統合とリージョン集約を組み合わせる場合、
Security Hub の管理アカウント（今回は委任管理アカウント）で Security Hub が有効化されていないリージョンでは、 Security Hub の設定で全リージョン集約の設定をしていても集約の対象に含まれません。

例えば、管理アカウントをSecurity Hub のメンバーアカウントへ追加した場合に
管理アカウント内の拒否リージョンの Security Hub で発生した検知については集約できない、
ということになります。

直接的な明言されている記述は見つかりませんでしたが、公式ドキュメントでは以下のように記載されています。

Security Hub は、アカウントで Security Hub が有効になっているリージョンからのみ、データを集約します。
Security Hub は、クロスリージョン集約の設定に基づいて自動的にアカウントで有効にされることはありません。
管理者アカウントがクロスリージョン集約を設定すると、Security Hub は、リンクされたリージョン内で、
その管理者アカウントのメンバーアカウントを識別します。
参考リンク：クロスリージョン集約の仕組み - AWS Security Hub

そこで、管理アカウントでは、委任管理の設定をしつつもメンバーアカウントへは追加せず
スタンドアロンの状態にすることで、管理アカウントだけ別個で全リージョン集約することが可能になります。

メリット

全リージョンで Security Hub が有効化されることで GuardDuty を有効化させていても他アカウントと同様、Security Hub 経由で通知の仕組みを実装させることができるかつ Security Hub によるセキュリティ対策を行うことができます。

デメリット

まず管理アカウントでは普段使用されていないリージョンでも検知する可能性があるという認知をしないといけない運用負荷は発生いたします。

また、通知の仕組みに対して管理アカウントのみの独自の経路を用意する必要があるためその負荷もあります。
しかし、こちらは EventBridge の通知をクロスアカウントで委任管理アカウントの EventBridge へ転送することで幾分か楽になります。
EventBridge のクロスアカウントの設定は下記を参照ください。
AWSアカウント間でAmazon EventBridgeイベントを送受信してみた | DevelopersIO

参照

終わりに

今回は、Security Hub をリージョン集約・Organizations 統合する場合の管理アカウントについて考えてみました。
今回取り上げた方法以外にも下記方法が考えられます。

Control Tower 管理外の OU 内へ委任管理用のアカウントを作成し、委任管理アカウントでも全リージョン Security Hub を有効化させる。
- Control Tower 管理外であればリージョン拒否の設定はカスタムとなるため
管理アカウントを Security Hub のメンバーアカウントとしつつ、拒否リージョン用に拒否リージョン内でリージョン集約の機能を有効化させる

管理アカウントに対して SCP を適用できたり、Control Tower のリージョン拒否コントロールが管理アカウントへも適用できればそれに超したことはないですが、現状ではブログ内で取り上げた方法があるかと思います。

運用とセキュリティを天秤にかけて、よりよい構成を選択いただければと思います。

この記事がどなかかの役に立てば嬉しいです。